Skip to content

p-token: Add unwrap_lamports instruction #87

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 8 commits into
base: febo/custom-entrypoint
Choose a base branch
from
Open

p-token: Add unwrap_lamports instruction #87

wants to merge 8 commits into from

Conversation

febo
Copy link
Contributor

@febo febo commented Sep 2, 2025 •
edited
Loading

Problem

In order to transfer out lamports from native SOL accounts, currently it is necessary to create and close ATAs or token accounts all the time.

Solution

This PR adds a new unwrap_lamports instruction that allows transferring out lamports directly to any destination account. This eliminates the need for creating temporary native token accounts for the recipient.

The new instruction uses the discriminator 3945, which is currently unused in Token-2022.

The amount to unwrap is specified as an Option<u64>:

  • None: the entire token balance is unwrap
  • Some(amount): the specified amount is unwrap

@febo febo requested a review from joncinque September 2, 2025 13:30
@febo febo force-pushed the febo/custom-entrypoint branch 2 times, most recently from fafdd3e to 8a3de38 Compare September 2, 2025 16:08
@febo febo force-pushed the febo/unwrap-lamports branch from 4409253 to 82fa3b5 Compare September 2, 2025 16:09
joncinque
joncinque reviewed Sep 2, 2025
View reviewed changes
Copy link
Contributor

@joncinque joncinque left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me! Just the bit on the discriminator. Also, be sure to get someone like @Arrowana to make sure it does what they need.

@Arrowana
Copy link
Contributor

Arrowana commented Sep 3, 2025 •
edited
Loading

This looks good to me! Just the bit on the discriminator. Also, be sure to get someone like @Arrowana to make sure it does what they need.

It looks ok, but should it have a feature similar to close, allowing unwrapping the entire available amount?

I see a few use cases for this unwrap_lamports:

  • A program which wants to support unwrapping, this PR already works then.
  • User interface / sdk which add convenience, in which case they call a program that might produce a variable amount, so amount is not fixed at execution but it should really unwrap all when they call it.

@febo
Copy link
Contributor Author

febo commented Sep 3, 2025

This looks good to me! Just the bit on the discriminator. Also, be sure to get someone like @Arrowana to make sure it does what they need.

Ir looks ok, but should it have a feature similar to close it allows unwrapping the entire amount?

I see a few use cases for this:

  • A program which wants to support unwrapping, this PR already works then.
  • User interface / sdk which add convenience, in which case they call a program that might produce a variable amount, so amount is not fixed at execution but it should really unwrap all when they call it?

So would it make more sense to always unwrap the entire amount or have both options?

@Arrowana
Copy link
Contributor

Arrowana commented Sep 3, 2025

This looks good to me! Just the bit on the discriminator. Also, be sure to get someone like @Arrowana to make sure it does what they need.

Ir looks ok, but should it have a feature similar to close it allows unwrapping the entire amount?
I see a few use cases for this:

  • A program which wants to support unwrapping, this PR already works then.
  • User interface / sdk which add convenience, in which case they call a program that might produce a variable amount, so amount is not fixed at execution but it should really unwrap all when they call it?

So would it make more sense to always unwrap the entire amount or have both options?

both options

@febo febo requested a review from buffalojoec September 5, 2025 00:13
@febo febo force-pushed the febo/unwrap-lamports branch from b9cdf7c to 369e713 Compare September 5, 2025 00:17
@febo
Copy link
Contributor Author

febo commented Sep 5, 2025

This looks good to me! Just the bit on the discriminator. Also, be sure to get someone like @Arrowana to make sure it does what they need.

Ir looks ok, but should it have a feature similar to close it allows unwrapping the entire amount?
I see a few use cases for this:

  • A program which wants to support unwrapping, this PR already works then.
  • User interface / sdk which add convenience, in which case they call a program that might produce a variable amount, so amount is not fixed at execution but it should really unwrap all when they call it?

So would it make more sense to always unwrap the entire amount or have both options?

both options

@Arrowana PR updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@joncinque joncinque joncinque left review comments

@buffalojoec buffalojoec Awaiting requested review from buffalojoec

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@febo @Arrowana @joncinque